Amazon EC2 セキュリティレシピ

#Amazon EC2

#AWS

阿部洸樹

2016.11.08

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

セキュリティという言葉は様々なシーンで使われます。マルウェア、暗号化、改ざん、スパム、ブルートフォースアタック、内部不正、ログ管理、ログ監視、DDoS対策など例をあげるときりがありません。

今回はAWSを利用する際にユーザーが最低限行うべき対応をご紹介します。 AWSには様々なサービスがありますが、以下のようなEC2 1台のWEBサーバを想定しそのセキュリティ対策を考えます。

ご紹介する項目は以下の通りです。

信頼できるAMIを使う
最新のOSを使う
必要なポート、必要な拠点のみ接続を許可する
最新のミドルウェアを使う
マネージドサービスに任せる
最新のアプリケーションを使う
IAMロールを使う
最低限のIAM Policyを設定する
日頃からAWSからのメールを確認する

信頼できるAMIを使う

EC2は基本的にAmazon マシンイメージ（AMI)から作成します。 AMIはAmazonやAWSパートナー以外の第三者も公開することが出来るため、悪意のあるAMIを利用しないように気をつけます。例えば、掲示板やブログに記載されたAMI-IDを確認せずに利用する事はやめましょう。

EC2コンソールでは、所有者をAmazonに絞って表示することが出来ます。 WindowsServer 2012R2の日本語版を表示する例を示します。

AWS Marketplaceから信頼できるパートナーやコミュニティが提供するAMIを利用する手もあります。 CentOSの場合、CentOS.orgが提供するAMIを利用すると良いでしょう。

必要なポート、必要な拠点のみ接続を許可する

EC2のアクセス制限は主にセキュリティグループで行います。セキュリティグループはファイアウォールに相当する機能です。接続を許可するプロトコル、ポート番号、送信元IPアドレスを記載します。

WEBサーバに適用するセキュリティグループの例をあげます。サービス公開用のHTTPSは、送信元に「0.0.0.0/0」を指定します。「0.0.0.0/0」とする事でインターネット全体からの接続を許可します。開発中は開発拠点からだけ接続できるようにしても良いでしょう。サービス利用者のIPが特定出来る場合は、利用者のIPを指定します。

管理用のSSHやリモートデスクトップは、最低限の許可を与えます。具体的には開発会社やAWS管理者などメンテナンス拠点のIPアドレスを指定します。

タイプ	プロトコル	ポート範囲	送信元
HTTPS	TCP	443	0.0.0.0/0
SSH	TCP	22	メンテナンス拠点のIPアドレス/32

マネージドサービスに任せる

セキュリティの観点からマネージドサービスを検討しましょう。マネージドサービスを利用する事で環境をセキュアにしつつ、TCOを下げる効果を期待出来ます。

スタンドアローンのEC2を例に考えます。アプリケーションの要件としてApache/PHP/MySQLが必要とします。ユーザーはWebサイトに"HTTPS"でアクセスします。 SSLを終端させるためにOpenSSLを利用し証明書をEC2上に配置します。

この場合、少なくともApache/PHP/MySQL/OpenSSLのアップデートが必要です。また、アップデートにはOSの再起動が必要だったり推奨される事が多いため、EC2スタンドアローン構成ではアップデートによるサービス影響が大きくなります。

マネージドサービスを利用するケースを考えます。SSL終端をELB、MySQLにRDSを使う構成とします。 EC2上のOpenSSLとMySQLが不要になり管理するミドルウェアの数を減らす事が出来ます。

ELBを使うメリットはほかにもあります。3つ挙げてみます。 1つ目にSSL終端にはCPUパワーを使うため、EC2の負荷を下げる事が期待出来ます。EC2はhttpとしてアクセスを受け取ります。 2つ目にAWS Certificate Manager(ACM)の無償のSSL証明書の利用です。ACMでは更新不要な証明書を利用できますが、EC2上に配置する事は出来ません。認証局から証明書を購入する費用や更新の手間が不要になります。 3つ目にアップデートに伴うサービス影響の軽減です。EC2利用費用はかかりますが、EC2を複数配置し順番にアップデート（ローリングアップデート）する事でサービスを継続しながらアップデートを行えるようになります。

RDSでは自動的にパッチ適用やバックアップを行います。また、冗長構成（Multi-AZ）を簡単にとる事が出来ます。 Multi-AZ構成の場合、パッチ適用のサービス影響は非常に小さくなります。 EC2で頑張らずにマネージドサービスに任せましょう。

IAMロールを使う

EC2からAWS CLIなどを実行する事があります。例えば、OS上のファイルをs3バケットにアップロードするようなケースです。 AWS CLIを実行するにはs3の利用権限が必要です。以前はIAMユーザのAccess Key、Secret Keyを使う方法が一般的でしたが、現在は推奨されていません。 Keyが流出し第三者に悪用されるケースがあるためです。具体的にはプログラムや設定ファイル中にKeyを記載し、意図せずKeyを公開してしまうといったケースです。

現在はIAMロールの利用が推奨されています。 IAMロールを利用する事で、EC2上にKeyを配置する必要がなくなります。

最低限のIAM Policyを設定する

前述のIAMロールには、IAM Policyを割り当てます。 IAM PolicyはJSON形式のアクセス許可を記述したドキュメントです。 IAM PolicyにはAWSが作成/管理するAWS 管理ポリシーとユーザーが作成/管理するカスタマー管理ポリシーがあります。

カスタマー管理ポリシーではより正確なアクセス許可を記述出来ますが、管理が複雑になりやすいです。セキュリティ要求が厳密に求められる場合に検討します。 AWS 管理ポリシーは、サービス毎に数パターン用意されています。 s3では「AmazonS3ReadOnlyAccess」「AmazonS3FullAccess」「AmazonDMSRedshiftS3Role」があります。（2016/11/6時点）基本的にはAWS管理ポリシーの範囲で最低限のIAM Policyを利用すると良いでしょう。 s3にファイルバックアップを行う場合には「AmazonS3FullAccess」です。むやみに「AdministratorAccess」など大きい権限を与えないようにします。

日頃からAWSからのメールを確認する

AWSからメールの中には重要なものが含まれる事があります。特にEC2のリタイアメントを受け取る機会が多いでしょう。インスタンスをホストしている基盤のハードウェアで回復不可能な障害が検出されると、AWSによってインスタンスのリタイヤが予定されます。インスタンスのStop及びStartの操作を行うことにより、EC2インスタンスをホストする物理マシンを変更し、AWSによるインスタンス停止を回避することが出来ます。期日までに回避操作を行わないと、EC2はStopされます。

不正利用を通知するAbuse reportについても留意が必要です。例えばインスタンスが第三者にのっとられた場合、DDoS攻撃に利用されるなど不正利用される場合があります。 AWSから不正利用が疑われる旨のAbuse reportが通知された場合、ユーザーは適切な対応を行いその旨をAWSに報告する必要があります。 Abuse reportはAccess Key、Secret Keyの流出が疑われる場合も通知されます。 AWSからのメールを確認し、重要な通知を見逃さないようにしましょう。